Troubleshooting
This document describes common problems that occur when working with the RWTH - Mindstorms NXT toolbox and how to avoid or work around them.
Contents
Bluetooth communication
Packet loss and timeouts
During bluetooth communication there is usually a short lag between each command transmission. This lag can be expected to not exceed 30ms at most, as stated in the official Mindstorms protocol documentation. From time to time however a significantly higher lag can be observed. A packet will then be delayed up to 10 seconds (this behaviour has only been verified when using Windows). The causes for this are likely to originate in the bluetooth stack or protocol itself and have yet to be closer examined. They seem to depend on the bluetooth signal strength, the used adapter model, the battery power of the robot and the system specification of the host computer.
When such a packet loss happens, the robot cannot be controlled during this time, e.g. a StopMotor command might not reach its target in time. That is why you should try to specify a certain rotational limit for the motor using SetAngleLimit. That way the motor will automatically stop at the correct position, even if the delay happens at the wrong time.
Fact is that we are experiencing a timeout period whose length can be adjusted. The default setting is 2 seconds, which reduces this period to a tolerable length. You can experiment with lower values, however do they have a drawback: Too short timeout periouds might cause real packet loss, meaning that data will actually be lost (because the bluetooth stack cannot retransmit the lost data in time). This usually results in error messages or strange warnings ("trying to collect a packet that was not requested"). Best performance depends on many factors, and the effects are unfortunately not always reproducable.
Light sensor
Varying sensitivity
The NXT light sensor measures brightness, actively or passively. Unfortunately, the detected intensity depends on the wavelength of the light and is not a linear function. Commonly spoken, warm light like sunlight or that produced by light bulbs results in a higher intensity, whereas cold light such as from neon lamps or white-blue LEDs only gets detected with lower intensity.
Hence a common problem is that daylight cannot be compensated by artifical light in such a way, that repeated measurements always yield the same values. So how do we cope with this?
If a robot should be able to work in all scenarios with different illumination, there are mainly two possibilities:
Either the program requests a reference each time it is started, i.e. one always has to measure a red and blue standard color if the program has to distinguish between those two colors. This is basically a calibration process, that might even be supported by future NXT firmware versions (an according datafield is already reserved).
The other way is to take the surrounding light into account: Measure the daylight (or artificial light) of the environment. This brightness can then be used to calculate the real brightness using the value obtained from the sensor.
Maybe the easiest way is to make sure the robot always operates in similar illuminated situations.
Ultrasonic sensor
Inaccurate results
For certain objects the ultrasonic sensor seems to not work at all, while for other objects the results are very precise (±1 cm). First of all you need surfaces that reflect ultrasound. Not suitable are usually things with very soft surfaces, especially cloth or fur-like structures. One of the most important things to consider is the angle the sensor is facing towards the object: Always try to make it 90°, e.g. drive straight towards a wall instead of askew.
Important: Round surfaces, just like bottles, are extremly difficult to outline accurately. They reflect the ultrasonic impulses in too many directions, hence you get echos of imaginary objects that are not really there. The spreading of the ultrasonic sensor is very wide anyway: Reflections from up to 30° degrees to each side are not uncommon. It is probably best to stick to flat, hard, big objects at first.
Motors
Internal error correction
The NXT motors have a certain way they always try to reach the most accurate position. This may lead to some unexpected effects. It only happens when using a certain rotation limit (specified by SetAngleLimit).
Imagine you want to rotate a motor 400 degrees. As you set a relatively high power, and a certain rotational moment is involved, the motor will turn further than its set angle limit. Basically at the exact position of 400, the power will be turned off, leaving the motor spinning in coast mode until it comes to a stop. Let us just imagine this would be at 500 degrees. The motor now "remembers" that is has just turned 100 degrees too much. The next time, when you issue another "rotate by 400" command, what do you expect? It will NOT be 900 = 500 (current position) + 400 (next step to move) and the additional coasting part (which was about 100 the last time in this given example).
The motor keeps an internal memory of cumulative commands containing angle limits. This means, when you send the second "move 400" command, the internal sum is now at 800. This is the new target to be reached. In this case it does not matter that you start at 500 already. The motor "realizes" that there are only 300 degrees missing until 800. Of course, there might be some spinning in coast mode again, so we will not end up at 800, but more likely at 800 + something (maybe = 900). Note that using the wrong point of view from the paragraph above, the calculation would have yielded 900 + something (maybe = 1000).
To put it another way, if the motor is off by 100 degrees one time, it will try to correct it the next time. This results in periodic movements that are "too far" or "too short", depending on what you send, and what you expect.
Important: Do not turn any motors by hand while the NXT is still turned on, unless you know exactly what you are doing. If the internal counters do not get reset properly, the NXT motor will try to "correct" these changes you made by hand the next time it receives a command containing an angle limit. If you want to make sure nothing of this has a bad influence, reboot the NXT or start an external program using the command NXT_StartProgram.
Synchronization and turn ratio
For driving robots, the regulation mode "synchronization" is very handy to drive straight lines or curves (commands SyncToMotor and SetTurnRatio). When sending multiple commands to synced motors, e.g. to drive a straight line, turn around, and drive another line, there might be some strange behaviour that looks like the previously mentioned error correction mechanism. It has been found that these problems can be fixed by calling the following functions inbetween the different track sections:
% turn off motors (to reset NXT-internal regulation/synchronization bits) StopMotor(LeftWheelPort, 'off'); StopMotor(RightWheelPort, 'off'); % reset angle counters (aka "BlockTachoCount") ResetMotorAngle(LeftWheelPort); ResetMotorAngle(RightWheelPort);
Performance
For better performance (especially when using USB connections on slow machines), it is recommended to run this toolbox function:
OptimizeToolboxPerformance
The command will replace some of the lowlevel functions with faster binary versions from your MATLAB installation. For more details, see help section "Optimizing Performance".
Debugging
Warnings and error messages
When an error in your MATLAB program ocurrs, there is usually more than one error message. The complexer the functions get, the longer those error messages will be. Read them carefully! Most of the time, they are the best clue you have in order to find out what went wrong. It can be a bit confusing when all those red words take up lots of space inside your command window, or when errors repeatedly occur again and again.
It might help you to clean up your command window from time to time using this handy command:
clc
Note that your command history will not be touched by this. The last results from your command window will be cleared however.
It can be amazing how clean an error message suddenly looks when starting the program again in an empty command window...